Verify each finding against the current code and only fix it if needed.

Inline comments:
In `@internal/config.go`:
- Around line 335-339: The code converts humanize.ParseBytes result (n uint64)
to int64 without checking overflow; add a guard after ParseBytes in the same
function (where n, err := humanize.ParseBytes(s) is used) that returns an error
if n > uint64(math.MaxInt64) (use math.MaxInt64) so the function returns a clear
overflow error instead of silently truncating/producing a negative int64; keep
the existing error message style (e.g., fmt.Errorf) when returning the overflow
error.

In `@internal/cosign.go`:
- Around line 134-136: The code currently forces a default cache TTL whenever
ttl <= 0 which overwrites explicit non-cacheable or already-expired responses;
change the condition so the default is applied only when ttl == 0 (unspecified),
and preserve ttl when it's negative (explicit no-cache/no-store/expired). Update
the check that references ttl and s.cfg.HTTPCacheDefaultTTL in
internal/cosign.go so it sets ttl = s.cfg.HTTPCacheDefaultTTL only for ttl == 0
and does not override ttl < 0.

In `@internal/endorsements.go`:
- Around line 104-106: The current check in endorsements.go overrides a TTL of 0
(which parseCacheTTL uses to mean "no-cache"/"no-store"/expired), causing
responses that should not be cached to get the default TTL; locate the code that
calls parseCacheTTL (reference parseCacheTTL and the local variable ttl) and
change the conditional so you only apply s.cfg.HTTPCacheDefaultTTL when ttl is
negative (e.g. change "if ttl <= 0" to "if ttl < 0"), preserving ttl==0 values
returned intentionally by parseCacheTTL.

In `@internal/fetch.go`:
- Around line 123-124: The function parseCacheTTL currently returns defaultTTL
as-is, allowing configured defaults >24h to bypass the documented cap; update
parseCacheTTL to clamp defaultTTL to a maximum of 24 hours (time.Hour*24) at the
start (or before any early return) so any return path that yields defaultTTL
respects the 24h cap; ensure existing logic that parses the Expires header still
applies the same cap to parsed values as well.

---

Nitpick comments:
In `@internal/endorsements_test.go`:
- Around line 384-386: The test case "no headers returns default" currently uses
time.Hour (the existing default) which masks implementations that ignore the
provided defaultTTL; change the sentinel TTL in that case to a distinct
non-default value (e.g., time.Minute or another constant) so the test exercises
the defaultTTL parameter, and make the same change for the other occurrence
referenced (the case at the later line). Update the test cases in
endorsements_test.go that set want: time.Hour for the no-headers scenarios to
use the new sentinel TTL and ensure any helper variables (e.g., defaultTTL) or
assertions still compare against that sentinel value.

Verify each finding against the current code and only fix it if needed.

Inline comments:
In `@internal/config.go`:
- Around line 316-325: Update the comment for parseDuration to accurately
reflect its behavior: state that it reads a viper string key and parses it as a
time.Duration and returns an error if the value is empty or cannot be parsed
(i.e., for empty strings and any unparseable duration strings). Reference the
parseDuration function and ensure the docstring no longer implies empty values
are allowed.

Verify each finding against the current code and only fix it if needed.

Inline comments:
In `@internal/config.go`:
- Around line 118-136: Parsed durations from parseDuration (used to populate
endorsementTimeout, httpCacheDefaultTTL, revocationRefreshInterval,
rateLimitStallTimeout, etc.) can be negative and must be rejected; after each
parseDuration call check if the returned duration is < 0 and return an error
(e.g., fmt.Errorf("%s: negative duration %s", "<config.key>", d)) consistent
with existing parseByteSize error handling so invalid negative timeouts/TTLs
fail fast. Ensure you update all places that call parseDuration in this block
and include the specific config key name in the error message to aid debugging.

---

Nitpick comments:
In `@internal/config.go`:
- Around line 316-344: Add table-driven tests in internal/config_test.go to
cover the new fail-fast paths in parseDuration and parseByteSize: write cases
that pass an empty/invalid duration string to parseDuration (e.g., "" and "5xs")
and assert it returns a non-nil error, and cases for parseByteSize that pass
empty string and an oversized value (a string that parses to > math.MaxInt64)
and assert errors; call the functions directly (parseDuration, parseByteSize)
and verify the error messages contain the problematic input to lock in the
behavior.

Verify each finding against the current code and only fix it if needed.

Inline comments:
In `@internal/config.go`:
- Around line 118-121: parseDuration currently accepts zero which breaks callers
that require positive durations (RevocationRefreshInterval used by
time.NewTicker, EndorsementClientTimeout used with
context.WithTimeout/http.Client.Timeout, and RateLimitStallTimeout used with
context.WithTimeout). Fix by making parseDuration return an error for zero
durations (treat zero as invalid) and update callers (e.g., where
endorsementTimeout is assigned in internal/config.go) to handle that error path;
alternatively, if you prefer per-callsite validation, add explicit checks that
parsed values for RevocationRefreshInterval, EndorsementClientTimeout, and
RateLimitStallTimeout are > 0 and return a clear error instead of allowing zero
to propagate.

Verify each finding against the current code and only fix it if needed.

Nitpick comments:
In `@internal/config.go`:
- Around line 122-146: Extract a helper named parsePositiveDuration that wraps
parseDuration and enforces a non-zero result (signature:
parsePositiveDuration(key string) (time.Duration, error)); replace the repeated
parseDuration + zero-check blocks (used for keys "http.cache.default_ttl",
"revocation.refresh_interval", and "ratelimit.stall_timeout") with calls to
parsePositiveDuration, and update the surrounding code to return the helper's
error directly where those durations are assigned (e.g., httpCacheDefaultTTL,
revocationRefreshInterval, rateLimitStallTimeout).